今天要繼續講轉職工作使用到的工具以及遇到的一些問題及處理方式。

公司的專案在製作圖表有使用到Cube.js這個工具，這應該是很多使用javascript開發網頁，有圖表需求的APP會使用到的工具。

極簡介紹Cube.js架構

（上圖摘錄之官網）

由上圖所示，一個典型的 Cube.js 生產集群由一個或多個 API 實例、一個 Refresh Worker、Redis 和一個 Cube Store 集群組成。

Cube.js && Redis

在使用這項工具開發時，有出現過圖表跑不出來，畫面出現TimeoutError: ResourceRequest timed out的問題。仔細去查詢了Cube.js的Doc之後發現，是因為在使用Cube.js時搭配使用的Redis所造成。

Redis用於管理隊列(queue)和查詢級緩存(query-level cache)。

在Cube.js在連線Redis有一些額外參數設定可以設定Redis Pool
CUBEJS_REDIS_URL提供 Cube.js，默認情況下將創建一個最少 2 個，最多 1000 個並發連接的 Redis 連接池，而CUBEJS_REDIS_POOL_MIN和CUBEJS_REDIS_POOL_MAX環境變量可以用來調整池的大小限制。

TimeoutError: ResourceRequest timed out

造成原因應是來自redis pool的設定

解法是將CUBEJS_REDIS_POOL_MAX和CUBEJS_REDIS_POOL_MIN設大一點，避免連接池不夠用。

If your maximum concurrent connections limit is too low, you may see TimeoutError: ResourceRequest timed out errors. As a rule of a thumb, you need to have Queue Size * Number of tenants concurrent connections to ensure the best performance possible. If you use clustered deployments, please make sure you have enough connections for all Cube.js server instances. A lower number of connections still can work, however Redis becomes a performance bottleneck in this case.(摘錄自cube.js)
(翻譯：如果您的最大並發連接限制太低，您可能會看到 TimeoutError: ResourceRequest timed out錯誤。根據經驗，您需要有Queue Size * Number of tenants並發連接以確保可能的最佳性能。如果您使用集群部署，請確保您有足夠的連接用於所有 Cube.js 服務器實例。較少的連接數仍然可以工作，但是在這種情況下 Redis 會成為性能瓶頸。）

你可會疑惑，既然他是效能的bottleneck那總可以捨棄不用Redis吧？！沒錯，Cube.js非需要使用Redis，如果你想在沒有 Redis 的情況下在生產中運行 Cube.js，你可以使用CUBEJS_CACHE_AND_QUEUE_DRIVER環境變量來memory，但沒有Redis就無法運行無服務器和集群部署，因為它用於管理查詢隊列。